home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20031118-20041115 / 000030_slash_dev_slas…_2000@yahoo.com_Tue Dec 2 09:30:17 2003.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Path: newsmaster.cc.columbia.edu!panix!news.maxwell.syr.edu!postnews1.google.com!not-for-mail
  2. From: slash_dev_slash_null_2000@yahoo.com (Mark Sapiro)
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Re: Problem in Kermit trying to get a file while sending it at the same time
  5. Date: 1 Dec 2003 16:13:25 -0800
  6. Organization: http://groups.google.com
  7. Lines: 65
  8. Message-ID: <deb126db.0312011613.1b889e6f@posting.google.com>
  9. References: <f0bb0f39.0311250532.1b93aad@posting.google.com> <slrnbs6r9i.oig.fdc@sesame.cc.columbia.edu> <f0bb0f39.0311260731.11d9eb29@posting.google.com> <f0bb0f39.0311261025.6fd175b5@posting.google.com> <slrnbsa0at.dm1.fdc@sesame.cc.columbia.edu> <f0bb0f39.0312010625.7751d0a7@posting.google.com>
  10. NNTP-Posting-Host: 209.182.169.133
  11. Content-Type: text/plain; charset=ISO-8859-1
  12. Content-Transfer-Encoding: 8bit
  13. X-Trace: posting.google.com 1070324006 11751 127.0.0.1 (2 Dec 2003 00:13:26 GMT)
  14. X-Complaints-To: groups-abuse@google.com
  15. NNTP-Posting-Date: Tue, 2 Dec 2003 00:13:26 +0000 (UTC)
  16. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14706
  17.  
  18. anthonypieper@cs.com (newexpectuser) wrote in message news:<f0bb0f39.0312010625.7751d0a7@posting.google.com>...
  19. > I think I understand the following in the article:
  20. > 
  21. > "Notice that failure leaves the partial file (if any) in the working
  22. > directory, where the central-site watcher process does not look for
  23. > it. Thus transient failures do no harm. The script can be run again
  24. > later.
  25. > 
  26. > The /DELETE switch on the PUT command removes the source file after,
  27. > and only if, it was uploaded successfully; this prevents it from being
  28. > uploaded again (you could also have it moved or renamed). This way,
  29. > even if the script is run again for the same file, it will fail
  30. > immediately because the file is no longer there. Or, if a file of the
  31. > same name is in the same place, it is a new file that should be
  32. > uploaded.
  33. > 
  34. > Now we can move the uploaded file from the server's working directory
  35. > to its ready directory (the syntax assumes a UNIX-like file system on
  36. > server):
  37. > 
  38. > 
  39. >   ftp rename \m(nameonly) ../ready/\m(nameonly)"
  40. > 
  41. > 
  42. > This solves my problem if I have a partial file, it will be transfered
  43. > into a directory (working) where my central-site server won't be
  44. > looking for it. Once this file has been dropped off 100%, then the
  45. > next time around I run to send files, I will then pickup a full file
  46. > in my working directory.
  47. > 
  48. > What I don't understand is with the above "ftp rename \m(nameonly)
  49. > ../ready/\m(nameonly)", how does this avoid moving the partial file
  50. > from the working directory to the ready directory, there will still be
  51. > a file in the working directory albeit a partial file and this command
  52. > will move it along to the ready directory.
  53.  
  54. Both Frank and Jeffrey have been responding to your questions and have
  55. really already provided the answers to the above, but I have a sense
  56. that you still don't get it, so here's a shot at what I think the
  57. confusion is.
  58.  
  59. Partial files occur in two ways.  One way is that a transfer is
  60. interrupted because of a communications error, a disconnect or
  61. whatever.  This may leave a partially transferred file on the
  62. receiver.  The material you quote above is dealing with this situation
  63. and here the sender deals with it by transferring the file to a
  64. "working" directory, testing this transfer (with "if failure" or "if
  65. success") and only after successful complete transfer, moving the file
  66. on the receiver to the "ready" directory.
  67.  
  68. The other kind of partial file that I think you're concerned about is
  69. a file that is in the process of being written by some other process
  70. when the sender considers it as a candidate for transfer.  In this
  71. case, it is up to the underlying operating system to either hide the
  72. presense of the partial file until the creating process is done with
  73. it, or to deny access to the file by another process until the
  74. creating process in done with it.  All real operating systems do this.
  75.  If the process that is creating this candidate file is a file
  76. transfer process that could actually terminate before the file is
  77. complete, then it too needs to use a "working directory"/"ready
  78. directory" scheme.
  79.  
  80. --
  81. Mark Sapiro msapiro -at- value net    The highway is for gamblers,
  82. San Francisco Bay Area, California    better use your sense - B. Dylan
  83.